Skip to content

Conversation

@turetske
Copy link
Collaborator

@turetske turetske commented Mar 5, 2025

-- This will enforce origin capabilities for scitokens -- Adjusted the scitokens origin tests in authorization_test.go to test this functionality
-- Added test files to xrootd/resources

-- This will enforce origin capabilities for scitokens
-- Adjusted the scitokens origin tests in authorization_test.go to test
this functionality
-- Added test files to xrootd/resources
@turetske turetske added origin Issue relating to the origin component security labels Mar 5, 2025
@turetske turetske added this to the v7.15 milestone Mar 5, 2025
@turetske turetske linked an issue Mar 5, 2025 that may be closed by this pull request
@turetske turetske requested a review from jhiemstrawisc March 5, 2025 16:13
Comment on lines +483 to +491
// This will be set to true if PublicReads are enabled as well and is slightly redundant
// as then a token wouldn't be needed for reads, but doesn't actually change the functionality
// The default if the acceptable authorization isn't set is "all", so we only care if
// Reads is Enabled without Writes or vice versa
if param.Origin_EnableReads.GetBool() && !param.Origin_EnableWrites.GetBool() {
issuer.AcceptableAuthorization = "read"
} else if param.Origin_EnableWrites.GetBool() && !param.Origin_EnableReads.GetBool() {
issuer.AcceptableAuthorization = "write"
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm interpreting this overall diff correctly, we're setting the issuer's acceptable authorization in the scitokens config per issuer. That's not quite the same as enforcing per-namespace capabilities, especially once #2103 is merged, which allows us to define the prefix<-->issuer relationship as a many-to-many.

Once that PR is in, I think we'll need to change the approach in this section to iterate through each export and determine what the individual issuer(s) for that export should support. That gets us closer to what we want, but still not all the way. Consider a trickier configuration like:

Origin:
  Exports:
    - FederationPrefix: /foo1
      StoragePrefix: /bar1
      Capabilities: ["Writes"]
      IssuerUrls: ["https://issuer1.com"]
    - FederationPrefix: /foo2
      StoragePrefix: /bar2
      Capabilities: ["Reads"]
      IssuerUrls: ["https://issuer1.com"]

In this case, two namespaces define conflicting capabilities but use the same issuer URL. My understanding is this requires us to set all as the acceptable_authorization because otherwise we'd reject tokens for one of the namespaces. But setting all means we'll accept tokens with the wrong scopes for both namespaces. And I don't think we can give two issuers different names for the two different prefixes while having them use the same issuer URL, because XRootD picks up the first URL match and ignores the rest.

Any ideas how we can work around this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we just have to use the "all", which is what's happening now. There isn't a way to adjust this without a greater change to the xrootd code. This is already not as granular as we'd like (no difference between write/create/modify, etc.) so I think we just need to take what we can get for now.

@@ -0,0 +1,35 @@
#
# Copyright (C) 2024, Pelican Project, Morgridge Institute for Research
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're officially changing the scitokens config template, can you update the copyright statements?


err := config.InitServer(ctx, server_structs.OriginType)
require.NoError(t, err)
viper.Set("Origin.Port", 8443)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know a lot of this code is going to get hit with merge conflicts so I'm not sure if this comment will be relevant soon, but can you switch any of the viper.Sets you touch to use param.XXX.GetName() for the key (the way it's done in line 786 here)?

// The default if the acceptable authorization isn't set is "all", so we only care if
// Reads is Enabled without Writes or vice versa
if param.Origin_EnableReads.GetBool() && !param.Origin_EnableWrites.GetBool() {
issuer.AcceptableAuthorization = "read"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you define "read" and "write" as constants or types?

// Either one is read and the other is write, in which case we want the default of
// all, or one is all and the other is read/write, and we'd still want it to be the default
// of all, which is equivalent to the empty string
return ""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm more in favor of using "all" in this case instead of relying on the empty string's default behavior. That should make it a bit easier for Fabio to understand the configs we generate without having to find comments in source code.

[Global]
audience_json = ["https://origin.example.com:8443"]

[Issuer Built-in Monitoring]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another note that should help out with these tests is that once #2103 is in, it'll be easier to test this by working with the slice of generated Issuers instead of working with the files on disk. Some of what I did in that PR might break assumptions about preserved ordering of issuers/base paths when everything is written to a file, so you won't be able to do a direct equality comparison. And working directly with the slice of issuers prevents us from having to write new scitokens configs like this every time we need to test a new edge case.

@turetske turetske modified the milestones: v7.15, v7.16 Mar 21, 2025
@jhiemstrawisc jhiemstrawisc modified the milestones: v7.16, v7.17 Apr 22, 2025
@turetske turetske modified the milestones: v7.17, v7.18 Jun 13, 2025
@turetske turetske modified the milestones: v7.18, v7.19 Jul 8, 2025
@jhiemstrawisc jhiemstrawisc modified the milestones: v7.19, v7.20 Sep 2, 2025
@jhiemstrawisc jhiemstrawisc self-assigned this Sep 4, 2025
@turetske turetske modified the milestones: v7.20, v7.21 Sep 4, 2025
@turetske turetske modified the milestones: v7.21, v7.22 Oct 9, 2025
@turetske turetske modified the milestones: v7.22, v7.23 Nov 18, 2025
@turetske turetske modified the milestones: v7.23, parking-lot Jan 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

origin Issue relating to the origin component security

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Origin capabilities may be bypassed in some cases

2 participants